\section{Introduction}
\label{sec_introduction}
%Security is an important issue 
Organizations, such as hospitals and financial institutions, have to ensure compliance with regulatory, industry and internal mandates. The Health Insurance Portability and Accountability Act  (HIPAA) \cite{USCongress1999} for health care organizations and the Gramm–Leach–Bliley Act (GLBA) for the financial services industry are examples of these regulations. Noncompliance can incur important financial and reputation losses, e.g. a financial institution can be fined up to \$100,000 for each violation of GLBA~\cite{LAWYERS.COM}. 

%Why MDE
Model Driven Engineering (MDE) is currently one of the most promising approaches to secure IT systems and infrastructures and provides many advantages over traditional code-based approaches. For example, it allows formal system analysis and the production of IT infrastructures that are secure-by-design or offering security capabilities by design. Moreover, the design of security using models abstracts unnecessary low-level implementation details, which simplifies expression of high-level requirements like regulations. 

% Challenges to MDS
Model Driven Security (MDS) however faces many challenges. One major challenge is developing models that are simple but, at the same time, expressive enough to correctly capture requirements found in regulatory and internal mandates such as privacy obligations \cite{Ni2008,Mont2004a} and usage controls \cite{Park2004}. This lack in the expressiveness of current MDS security models has been recognized in \cite{Basin2011} where the authors recognize that ``{\it many systems have security requirements that go beyond access control, for example, obligations on how data must or must not be used once access is granted}''.
Indeed, most current MDS approaches only consider access control requirements \cite{Lodderstedt2002,Mouelhi2008,Morin2010a,Basin2011}, and therefore they do not cover, for example, HIPAA and GLBA regulations which often correspond to obligation requirements \cite{Ni2008}, e.g. an obligation to send customers a notice every year for as long as the customer relationship lasts or an obligation to notify a patient upon the disclosure of his personal health information to a third party. 

Another MDS challenge is update of security requirements at runtime. In most current MDS approaches, security is integrated with the business logic at compile time, making resulting systems incapable of complying with newly enacted security requirements and regulations. Furthermore, current approaches do not provide means to monitor security violations. Consequently, violations can not be dealt with by, for example, activation of new security rules. %Keeping a clear traceability between the security model and its IT enforcement is another important factor that must be considered to ensure that requirements are correctly enforced by the infrastructure.

In this paper, we propose an MDS approach fulfilling the aforementioned requirements. More specifically, we introduce a security Domain Specific modeling Language (DSL) to support expression of fine-grained advanced security policies and to automate the generation of security components to enforce these policies in a target application. In this paper, we focus on Java business applications, however our approach suits well with any object-oriented language for implementing business applications, with a few adaptations. Using the DSL, security officers can specify both obligations and authorizations (access control) and, therefore, many practical requirements found in internal and regulatory mandates are covered. The elements necessary to bind security requirements specified using the DSL to system models are also included in the model to clarify and declaratively map security policy elements to their counterparts in the target system (the system to be secured using the DSL). Furthermore, given a security model, we automatically generate security components necessary to enforce the policy in the target system. Security components provide monitoring capabilities, enabling the enforcement of reaction policies upon detection of security violations, in addition to enforcement and management of access control and obligation policies.

%The architecture generated to enforce security requirements complies with the Policy Enforcement Point (PEP) - Policy Decision Point (PDP) architecture allowing policy update at runtime if necessary. To ensure the traceability between security requirements in the policy and the target application, security policy concepts are explicitly mapped to their corresponding concepts in the application using the DSL. Moreover, policy violations are monitored and it is possible to define reaction policies to deal with violations when they occur.

%Paper outline
The paper is organised as follows. Section \ref{sec:motivation-approach} presents an overview of our work and discusses some of the challenges that \textsc{Mds} is currently facing. Section \ref{sec:DSL} describes \SAR (a shortcut for \emph{Security@Runtime}), our \textsc{Dsl} proposal for dealing with the identified challenges, and gives a general idea on the \textsc{Dsl} semantics. Section \ref{sec:Validation} shows performance results of our tool prototype on two real systems. Section \ref{sec:RW} discusses the approach, contrasting it with existing work. Finally, Section \ref{sec:Conclusion} concludes with some perspectives and future work.
